In response to the ongoing exhaustion of addresses available with the current Internet protocol (IPv4), IPv6 has started to come into practical use as a next-generation Internet protocol improved to enlarge address space, provide additional security and transmit data in accordance with priority. The specifications of the IPv6 protocol are such that a plurality of addresses are can be allocated to a single network interface. For example, a link local unicast address (referred to as a “link local address” below) and a global unicast address (referred to as a “global address” below) are known as addresses that can be allocated. Furthermore, since a plurality of addresses can be allocated as global addresses, there are cases where an IPv4 address and a plurality of IPv6 addresses are registered with respect to a single host in a DNS (Domain Name System) server.
An FQDN (Fully Qualified Domain Name) usually referred to as a “name” is in use in order to identify a communicating party. It should be noted that an FQDN is a host name or domain name indicated from a root along the hierarchical structure of a DNS domain. An FQDN will be referred to simply as a “name” below. When a DNS server is queried about a binary address by designating a name, there are instances where a plurality of IPv6 addresses are acquired. It is not necessarily possible for all of these addresses to be reached from the personal computer that was the source of the inquiry. In TCP communication using IPv6, an attempt is made sequentially to connect to a plurality of addresses obtained as the result of name resolution using the DNS and the address prevailing at the moment a connection succeeds is used as the party's address. With UDP (User Datagram Protocol) communication using IPv6, an application must verify reachability by using a method such as packet resend with respect to a communicating party. Accordingly, in essentially the same way as TCP communication, an attempt must be made to transmit a packet to a plurality of addresses in sequential fashion. Thus, IPv6 communication invites an increase in network traffic and trial time until a connection is established, these essentially being attendant upon the fact that a plurality of addresses are used.
Similarly, a plurality of addresses exist also as local addresses opposite an address of a communicating party. When the address of a communicating party is decided, the local address corresponding to this address is selected in accordance with an algorithm defined as RFC 3484 [“Default Address Selection for Internet Protocol version 6 (IPv6)”]. Since this address selection algorithm is executed within a program, usually referred to as a “protocol stack”, which is nearly an operating system, an application program cannot participate in relation to the local address selected.
Owing to the fact that a plurality of IPv6 addresses exist for each of two communication end points, the situation described below arises in a case where communication using the UDP protocol in particular is carried out. Assume that communication end points A and B each have three of their own IPv6 addresses and that these are Addr_A1, Addr_A2, Addr_A3 and Addr_B1, Addr_B2, Addr_B3, respectively. Assume that among the addresses possessed by communication end point B, the two addresses Addr_B1 and Addr_B2 have been registered with the DNS.
In a case where communication end point A starts communicating with communication end point B, as illustrated in FIG. 3A, first communication end point A designates the name of communication end point B (here the name will be “communication end point B”) and requests (queries) the DNS server for name resolution. The DNS server sends back (responds with) the two addresses (Addr_B1 and Addr_B2) as the result of name resolution.
The communication end point A that has received the result of name resolution transmits a request to Addr_B1 and reaches the communication end point B. The communication end point B sends back a response corresponding to the request. At this time, however, the communication end point has ascertained that Addr_A1 is the address at the source of transmission of the request and therefore it sends back its response to this address. When this is done, the address selection algorithm defined in RFC 3484 mentioned above functions and there are instances where Addr_B3 rather than Addr_B1 is selected as the optimum address from among the three addresses possessed by communication end point B. Thus, the response from communication end point B is sent from Addr_B3 to Addr_A1 of communication end point A. Thus a situation arises in which, from the standpoint of communication end point A, data is sent to it from an unknown address.
There are instances where, if it has been confirmed that the party to which the communication end point A sent the request is only the communication end point B, then the data from the unknown address can be determined to be a response sent from communication end point B. However, it will be understood that this determination is not possible if consideration is given to a case where, as shown in FIG. 3B, communication end point A sends requests to the two parties at communication end points B and C substantially simultaneously. Assume that the addresses of communication end points A, B and C in FIG. 3B are Addr_A1, Addr_A2, Addr_A3; Addr_B1, Addr_B2, Addr_B3; and Addr_C1, Addr_C2, Addr_C3, respectively. Furthermore, assume that those addresses among the addresses of communication end point B that have been registered with the DNS server are Addr_B1 and Addr_B2, and that such addresses of the communication end point C are Addr_C1 and Addr_C2. Assume also that the communication end point A queries the DNS server regarding the names of the communication end points B and C and that it receives two addresses per end point as responses. Here the communication end point A sends requests to the communication end points B and C, the communication end point B sends a response from Addr_B3 to Addr_A1, and the communication end point C sends a response from Addr_C3 to Addr_A1.
The communication end point A thus receives data from the unknown addresses Addr_B3 and Addr_C3. The communication end point A cannot determine from which of the communication end points B and C these two items of data have been received as response data. In the case of a protocol such as IPv4 in which a response can always be expected to be sent back from the address at the transmission destination of the request, such a problem cannot arise because the communicating party can be identified by a set of addresses that include the port numbers of both communication end points. In the event that the address at the source of transmission of a response packet does not match the address at the transmission destination of a request packet under these circumstances, a security-related problem arises, namely that address-based packet filtering for refusing acceptance is no longer carried out.
Specifically, since there is the possibility that a data packet that has been sent from an unknown address will be an authorized response to a request packet, it is not filtered and cannot be discarded. This means that any packet whatsoever must be received.
With the aim of improving upon the increase in traffic and processing delay that accompany name resolution in an DNS server, there is a method of deciding, based upon past performance, which protocol should be used to access a server in which IPv4 and IPv6 addresses have been registered (see the specification of Japanese Patent Laid-Open No. 2007-19612). The prior art disclosed in Japanese Patent Laid-Open No. 2007-19612 mainly assumes a situation in which IPv4 and IPv6 are mixed. It correlates and caches an IP protocol, with which it was possible in the past to communicate with a server process attempting to be accessed, with the server process and attempts to utilize this IP protocol and the corresponding address the next time access is made. This prior art is effective in reducing access to a DNS server and in reducing needless address access tries in a case where the server process does not wait for all protocol addresses that have been registered in the DNS server.
However, in a situation in which a response from a server process is sent from an unknown address, caching itself is not carried out and the problems set forth below cannot be solved even with the invention disclosed in Japanese Patent Laid-Open No. 2007-19612.
1. Basically, response data from an address other than an address selected as a transmission destination must be received. That is, there is a problem in terms of security, namely that address-based packet filtering must be removed.
2. With an application that performs communication using addresses of both the IPv4 and IPv6 protocols, the number of times the DNS server is queried regarding name resolution increases. This increases traffic and delays response time.
3. In a case where a plurality of IPv6 addresses for a single communication end point have been registered with a DNS server, there is the possibility that packet transmission will be performed using all of the plurality of addresses. In other words, traffic increases.